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Cross Reference to Related Application 

This application claims the benefit of U.S. provisional application serial number 
60/224,052, filed August 9, 2000. 

Background of the Invention 

The present invention relates, in general, to programmable medical instruments 
for computing probabilities of medical outcomes or diagnoses.. 

A number of instruments have been developed that enable the physician to 
compute probabilities of life threatening cardiac conditions for patients. Some of these 
instruments are described in the following references, all of which are incorporated 
herein be reference. 

A hand-held predictive instrument is described by Michael W. Pozen et al. in "A 
Predictive Instrument to Improve Coronary-Care- Unit Admission Practices in Acute 
Ischemic Heart Disease" The New England Journal of Medicine, Vol 3 10 pp. 1273-1278, 
May 17, 1984. With the handheld calculator-based instrument, a physician can compute 
a patient's probability of having acute cardiac ischemia based upon physician-entered 
values for a set of clinical variables. An automatic, computerized version of this 
instrument which utilizes output from a electrocardiograph and a waveform analyzer is 
described by H. P. Selker et al. in "A Time-Insensitive Predictive Instrument for Acute 
Myocardial Infarction Mortality 1 ', Med. Care 1991; 29:1196-1211. 

A predictive instrument for determining the probability of acute hospital mortality 
of a cardiac patient is described in U.S. Pat No. 4, 957,1 15 to Dr. Harry P. Selker, and 
incorporated herein by reference. The probability of acute hospital mortality is 
commonly understood to mean the probability of dying from a current acute condition, 
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generally during the specific initial hospitalization for the problem. It is also know as the 
probability of imminent death for the patient. That is, it is a short term, as opposed to a 
long term, probability of mortality that does not necessarily have a precisely defined 
period of time associated with it. 
5 A predictive instrument for evaluating whether to use thrombolytic therapy to 

treat a patient with a heart condition is described in U.S. Pat. No. 4,998,535 to Dr. Selker 
et al, and incorporated herein by reference. The predictive instrument computes a first 
probability of acute hospital mortality for the patient assuming that thrombolytic therapy 
is not administered and it computes a second probability of acute hospital mortality for 
10 the patient assuming that thrombolytic therapy is administered. The difference in the 
computed probabilities may assist the physician in deciding whether it would be 
advantageous to administer the thrombolytic therapy to the patient. 

O The above-mentioned predictive instruments use logistic regression equations to 

model the probability that the patient has a serious cardiac condition (e.g. the probability 

!j| 15 of acute cardiac ischemia or the probability of imminent death from a cardiac condition). 

p Such predictive instruments have also been suggested for other medical conditions or 

fy medical outcomes. See for example, U.S. Pat. No. 5,724,983 to Dr. Selker et al. also 

^ incorporated herein by reference. 

yy 

w 20 

S Summary of the Invention 

iM In general, in one aspect, the invention features an apparatus for monitoring the 

medical condition of a patient. The apparatus includes a monitoring device which during 
use monitors one or more clinical features of the patient; a predictive instrument arranged 

25 to receive output from the monitoring device and programmed to compute a probability 
of a medical outcome or diagnosis based on the monitored one or more clinical features; 
and an interface through which a user enters information characterizing the patient. The 
predictive instrument is programmed to request an algorithm which models the medical 
outcome or diagnosis from a remote location and is further programmed to compute the 

30 probability by executing that algorithm. 

Preferred embodiments may include one or more of the following features. The 
monitoring device is an electrocardiograph. The algorithm enables the predictive 
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instrument to compute said probability using a regression equation. More specifically, 
the regression equation is of the form: 

i> = 100 1 

where P is the probability of medical outcome or diagnosis, b 0 is a constant, the xi's are 
5 explanatory variables, and the bi 's are coefficients of corresponding explanatory 
variables. Also, in some cases P is a probability of acute cardiac ischemia. 

In general, in another aspect, the invention features an apparatus for enabling a 
remotely located predictive instrument to compute a probability of a medical outcome or 
diagnosis based on monitored one or more clinical features of a patient. The apparatus 
10 includes a data storage area which stores a plurality of different algorithms, each of 
Q which models a corresponding medical outcome or diagnosis; and a server which is 
ji programmed to respond to a request from a remote device by retrieving a selected one of 
W the plurality of different algorithms from the data storage and forwarding the selected 

m algorithm to the remote device. 

U\ 15 In preferred embodiments, the request contains a patient profile and the server 

s identifies which of the plurality of different algorithms is the selected algorithm based on 

■ w 

ffi the received patient profile. 

y In general, in still another aspect, the invention features a method for evaluating a 

O medical condition of a patient. The method includes receiving input characterizing the 
20 patient; electronically retrieving from a remote location, an algorithm tor computing a 
probability of a medical outcome or diagnosis; monitoring one or more clinical features 
of a patient; and using the retrieved algorithm to compute the probability of the medical 
outcome or diagnosis for the patient and based on the monitored features. 

In one aspect, the invention features an improved method and system to distribute 
25 matched analytical and diagnostic software components to an individual patient. 

In another aspect, the present invention features an improved method and system 
in which existing analytical and diagnostic software components can be improved upon 
and support the creation of new analytical and diagnostic software components for patient 
groups that have not been adequately addressed by prior art methods and systems. 
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In another aspect, the present invention features an analytical and diagnostic 
software component lookup service to make available existing analytical and diagnostic 
software components to compliant networked instruments and systems. 

In general, in one aspect the invention relates to a new method and system to 
5 provide lookup and distribution of individualized medical analytical and diagnostic 

software components over a network, including, but not exclusively within an intranet or 
the Internet and, in particular, to enable appropriately equipped networked medical 
instruments and systems to lookup and request appropriately matched analytical and 
diagnostic software component(s) for improved patient management and care. In other 
1 0 words, the invention provides the framework in which better analytical and diagnostic 
software components may be created, improved, and made available to subsequent 
patients through their patient healthcare providers. 

0 In general, in another aspect the invention has applicability to medical systems 
■sfl use d to address cardiovascular diseases. Many prior art methods and systems in this area 

1 {; 15 utilize analytical and diagnostic software components based on narrowly derived patient 

population and characteristics. In particular, many prior art methods and systems in 
f|j electrocardiographic instruments and systems analysis and diagnostic are based on a 

JU fixed analytic and diagnostic software component for a general population of Caucasian 

CI middle age males and to some extent middle age Caucasian females. In the area of 

S 20 cardiovascular diseases, the invention provides a method and system to enable both the 
.J*f availability and creation of highly individualized analytical and diagnostic software 

component based on a patient's presenting demographics and locality. Thus, this 
application of the invention enables a much more appropriate application of prior medical 
knowledge and practices. 
25 According to some embodiments of the invention, the method and system work 

by designing and implementing individual analytical and diagnostic software components 
according to Object Oriented practices to a pre-defined interface or application 
programming interface (API). An interface or API provides, in terms of computerized 
software, a "contract" upon the software component that implements the API to provide 
30 for a set of "methods" or functions or procedures as defined by the API. This enables the 
framework in which the software component is loaded to service requests by the 
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framework or container upon the loaded software component. 

Specifically, those embodiments of the present invention implement these 
software components as both Java Beans and Enterprise Java Beans. The framework or 
container in which these Java components are loaded can be network enabled 
5 applications that supports loading and executing Java Beans and Enterprise Java Beans. 
Of course, other components framework and technologies such as Microsoft's 
COM/COM+ and DCOM can also be used to implement this invention. 

The method and system also provide for a repository of all available analytical 
and diagnostic software components. This repository supports intranet and Internet 
10 lookup services via the Java Naming and Directory Interface (JNDI) repository lookup 
technology. This lookup service enables compliant instruments and system to query all 
available analytical and diagnostic software components that best match a patient's 
demographic and geographic profile. 

The method and system also provide for a feedback mechanism in which clinician 



^ 15 directed diagnosis and patient outcome information can be feed back to enable the 



development of new and improved analytical and diagnostic software components to be 
placed in the analytical and diagnostic software components repository. 

Therefore the present invention provides a self-improving and self-sustaining 
p system for providing distributed analytical and diagnostic software components. The 
j| 20 quality of the analytical and diagnostic software components will increase over time and 
with each patient served by this system. 

In some aspects, the invention also provides dynamic medical analytical 
intelligence for medical instruments based on a patient's particular profile and desired 
analysis requirements. And it enables small and low-cost medical instruments to be 
25 produced without the need to implement a full range of analytical analysis capabilities; 
thus reducing the overall development and manufacture and extending the useful life 
cycle of the instrument. In addition, in other aspects the invention provides a framework 
to support components based medical analysis over a distributed network environment 
and it supports a distributed medical analysis through the use of a federation of 
30 development centers and service providers. Also, new and existing medical analysis 

components can be automatically and manually created, updated, and distributed over a 
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networked environment. 

The details of one or more embodiments of the invention are set forth in the 
accompanying drawings and the description below. Other features, objects, and 
advantages of the invention will be apparent from the description and drawings, and from 
the claims. 

Brief Description of the Drawings 

Fig. 1 is a block diagram of a system which embodies the invention; 
Fig. 2 shows the functionality of the Network-enabled Medical Instrument shown 
in Fig. 1; 

Fig. 3 shows the functionality of the Analytical Service Provider that is shown in 

Fig. l; 

Fig. 4 shows the functionality of the Analytical Algorithm Development Center 
that is shown in Fig. 1; 

Fig. 5.1 shows a representation of an Algolet component; 

Fig. 5.2 illustrates the relationships among Algolet components; and 

Fig. 6 presents a flowchart of the Algolet lookup method implemented by the 
networked medical instrument and the Analytical Service Provider. 

Detailed Description of the Preferred Embodiments 

Fig. 1 is a high level diagram of an embodiment of the invention according to 
which a patient 2 receives an analysis appropriate to the patient's specific characteristics 
or profile through the interaction of a medical instrument 3 over a network or 
communication connection 4 to an Analytical Service Provider system 12. The analytic 
services provided to medical instrument 3 can be continually improved upon; moreover, 
new analytical services can be created and provided for use by other compatible medical 
instruments. 

In the embodiment shown in Fig. 1, medical instrument 3 utilizes and gains 
analytical intelligence first from its local algorithm repository and then from a remote 
algorithm repository to satisfy the needs of the particular patient with a specific patient 



profile. Medical instrument 3 predicts the probability of acute cardiac infarction for a 
given patient utilizing a network enabled electrocardiograph. Acute cardiac infarction is a 
condition in which the heart has lost significant blood flow, causing the onset of 
permanent cardiac muscle damage. The use of an electrocardiograph medical instrument 
is common practice in detecting and diagnosing such condition. The accuracy of 
identification and diagnosis of such condition is greatly dependent on many factors such 
as time since actual onset of the condition, patient's age, patient's gender, patient's weight, 
and other factors that are taken into consideration by the medical instruments shown here. 
In addition, the medical instrument automatically adapts its analytical capabilities to best 
suit a patient's immediate needs. 

In the illustrated embodiment, there are three main high-level components. There 
is medical instrument 3 including a monitoring or measurement component, such as an 
electrocardiograph, connected through common means such as wired electrodes 5 to 
patient 2. Medical instrument 3 executes analysis of the patient's biological condition 
through the use of the patient's particular demographics, referred to herein as a patient's 
Profile, containing such information, but not limited to, age, gender, medical history, race, 
and other information describing the patient. Medical instrument 3 utilizes its local 
analytical capabilities to perform the requested analysis. If the local analytical capabilities 
are insufficient to provide such analysis, the medical instrument communicates over a 
locally connected or remotely connected network with one or more Analytical Service 
Providers 12. The network may be, but is not limited to, an intranet, the Internet, or a 
wireless network. To perform the required analysis, medical instrument 3 requests certain 
analytical software components, referred to herein as Algolets, from one or more available 
Analytical Service Providers 12. 

Each Analytic Service Provider 12 utilizes the services of an Analytical 
Development Center 13 to provide continual automatic and manual updates to its 
repository 14 of analytical components (Algolets)as well as new analytical components 
for the identification and diagnosis of new diseases. Analytical Development Center 13 
utilizes a database 15 of patient profiles, clinical presentations that might include, but are 
not limited to, electrocardiographic waveforms and signals, biological measurements such 
as chemistry, temperature, genetic information, and independently confirmed disease 



diagnoses by other appropriate clinical entities, such as a physician, to manually and/or 
automatically generate mathematical models and algorithms for identifying and 
diagnosing medical conditions and diseases. Each mathematical model and algorithm for 
example can therefore be tailored to a specific patient population or Profile such as, but 
not limited to, African Americans between the age of 50 and 65 with known history of 
hypertension. 

Such mathematical models and algorithms are then packaged as an Algolet, which 
will be described in detail below and illustrated in Fig. 5, and delivered to the Analytic 
Service Provider 12. 

Networked Medical Instrument 

Fig. 2 depicts the components of medical instrument 3 that utilizes the services 
provided by the Analytical Service Provider to request the best available matched 
analytical software algorithm components for a specific patient profile. It also depicts the 
feedback from a clinician 28 reviewing the reported analysis results that is used by 
Analytical Algorithm Development Center 13 for improving existing algorithms as well 
as the creation of new analysis algorithms that will be made available to Analytical 
Service Provider system 12. 

Patient 21 requires analysis of possible acute cardiac infarction. Patient 21 enters 
his/her Profile data, consisting of, but not limited to, age, gender, weight, and family 
history using the medical instrument's Patient Profile Entry interface 22. Patient Profile 
entry can be done as part of pre-configuring the medical instrument. This is appropriate 
for patient information that does not change over relatively short periods of time and 
might include, but not be limited to, date of birth, race, and past medical conditions such 
as hypertension and diabetes. Other patient Profile information can be entered in real- 
time or just prior to execution of an analysis which might include, but is not limited to, 
heart rate, blood pressure, and temperature. A patient Profile created internally by the 
medical instrument is a XML record using plain ASCII text representation or as a binary 
Document Object Model (DOM)structure. For example, the patient Profile may appear 
as the following XML document: 
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<patientProfile DATE="04/06/2000 14:23:33" DATEFORMAT="M/dd/yyyy h:m:s" ID="iMedical Systems Inc. 
IMSI200"> 
<demographics> 

<property ID="RACE">African American</property> 
<property ID="AGE">56</property> 
<property ID- , GENDER">Male</property> 
</demographics> 
<medicalHistory> 

<medHx ID^'Hypertention" DATE="0/1 2/1982 ,, DATEFORMAT= ,, M/dd/yyyy7>treated</medHx> 
</medicalHistory> 
<vitaISigns> 

<property ID="SBP">87</property> 

<property I D =" D B P" > 1 22</property> 

<property ID- TEMPERATURE" UNiTS=" DEGREE">98.6</property> 
<property ID-'HEARTRATE" UNITS=" BPM">94</property> 
</vitalSigns> 
</patientProfile> 

XML is a self-describing language that provides a human readable descriptive 
method for describing structured data such as a patient Profile. Furthermore, the internal 
representation of the XML-based patient Profile using the DOM construct provides 
adaptive and flexible representation of the same structured data. The above patient 
Profile example illustrates a case where the patient is a male African American of age 56 
years with a past medical history of hypertension. 

The patient Profile entered through interface 22 is passed to an Algolet Lookup 
Service 23 that will attempt to find, based on patient Profile matching, the most 
appropriate analysis software component that can provide the requested analysis. Lookup 
Service 23 first consults a Local Algorithm Repository 25. A detailed description of 
Algolet Lookup Service 23 is provided below and illustrated in Fig. 6. If Local Algorithm 
Repository 25 does not have an Algolet that can provide the requested analysis matching 
the patient Profile, Algolet Lookup Service 23 will connect to one or more pre-defined 
Analytical Service Providers over a secure network 24, such as, but not limited to, an 
intranet, the Internet, or wireless network, to acquire the most appropriate analysis 
capability that best matches the patient's Profile. This ability to consult external sources 
for acquisition of analytical software components provides extensive flexibility and 
expansion capabilities without having to create a new medical instrument to host such 
capabilities. 

Once the appropriate or best analysis software component(s)have been identified 
and downloaded over a communication link 24 from a remote Analytical Service 
Provider, it is first added to Local Algorithm Repository 25. Local Algorithm Repository 
25 is managed by the medical instrument using various methods such as, but not limited 



to, memory availability, first-in-first out algorithm, or most frequently used Algolet 
algorithms. The analysis software component(s)is then passed onto an analysis 
component 26 for execution utilizing additional patient biological signals such as the 
cardiac electrical signal in the form of a 3 -lead or 12-lead or 16-lead electrocardiogram. 
Once the analysis is complete, the biological data and results of the analysis are 
forwarded to a reporting module 27 for presentation to a clinician 28 for confirmation and 
review. In addition, the biological data and analysis results are also archived locally 
and/or forwarded via a data storage communication link 29 to a remote database storage 
facility such as the Analytical Algorithm Development Center (as illustrated by 
communication link 210). Clinician 28 or another medical professional or information 
system involved in the care of the patient can then forward confirmed findings and 
diagnosis information to the Analytical Algorithm Development Center for storage, as 
illustrated by a secure network communication link 211. 

It should be readily apparent that such a medical instrument will, through use, 
acquire specific intelligence that will best serve its particular patient population. This is 
achieved without prior knowledge of the particulars and specifics of the patient 
population it will serve. This is ideal for medical instruments that have limited system 
resources both in terms of local storage and computational facilities. Instead of having to 
include an analysis capability designed for a broad patient population which only provides 
limited analysis accuracy or instead of requiring large local storage to facilitate many 
more analysis capabilities, the described embodiment can be implemented with low-cost 
medical instruments having very modest storage and computational requirements. In 
addition, the described embodiment achieves highly adaptive and patient specific 
analytical capability. One can also use a variety of different consumer devices such as 
wireless cell phones and networked computers for personal healthcare and medical use. 

Analytical Service Provider 

Fig. 3 depicts the details of Analytical Service Provider 12. More specifically, 
Fig. 3 depicts the components utilized to match the profile to the analytical algorithm 
software component, to perform the algorithm software component lookup and retrieval 
methods, and to implement the automated and continual algorithm software component 
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update service from the Algorithm Development Center. 

Analytical Service Provider 12 is a locally or remotely located network server 
and database repository. Requests from medical instruments, such as described above, 
arrive as secure messages over Hyper-Text Transport Protocol (HTTP)over 
communication link 24 and are received by a Network Server 3 1 . Server 3 1 utilizes a 
standard secure Internet Web-Server capable of receiving and processing industry 
standard HTTP messages. The message arriving at Network Server 3 1 is an extended 
XML message consisting of a patient Profile document such as mentioned above and 
requesting the particular analysis the network connected medical instrument desires. 
Below is an example of the XML-based message used in the described embodiment: 

<ana!ysis DATE ="04/08/2000 15:13:22" DATE FOR MAT-' M/dd/yyyy h:m:s" ID=" iMedica! Systems Inc. IMSI200" 

ID="Acute Myocardial Infarction", 

<action TYPE- 1 LOOKUP" TIMELIMIT-' 00:02:007> 

<property ID="INF AMi">required</property> 

<property ID="ANT AMI">required</property> 

<property ID- 'POST AMr>desired</property> 
</analysis> 

<patientProfile DATE-' 04/08/2000 14:23:33" DATE FORMAT-' M/dd/yyyy h:m:s" ID=" iMedical Systems Inc. 
1MSI200"> 
<demographics> 

<property ID="RACE">African American</property> 

<property ID= ,l AGE">56</property> 

<property ID="GENDER">Male</property> 
</demographics> 
<medicalHistory> 

<medHx ID="Hypertention" DATE="06/12/1982" DATEFORMAT="M/dd/yyyy">treated</medHx> 
</medicalHistory> 
<vitalSigns> 

<property ID="SBP">87</property> 

<property ID- 'DBP">1 22</property> 

<property I D="TE MPER ATU R E" UNITS=" DEGREE">98.6</property> 
<property ID="HEARTRATE" UNITS=" BPM">94</property> 
</vitalSigns> 
</patientProfile> 

This XML-based message indicates the analysis type - 1 Acute Myocardial 
Infarction' 1 is desired for the diagnosis of possible Acute Myocardial Infarction by the 
medical instrument - a condition indicating significant decrease in blood supply to the 
cardiac muscles and thus impending permanent damage to the heart muscles. 

Server 3 1 will forward the patient Profile to a processing module 32. Processing 
module 32, utilizing a search engine 33, first executes a patient profile match to all 
known Algolets that are capable of providing the desired analysis capabilities. In the 
described embodiment, search engine 33 includes a database registry of patient 
characteristics and its associated Algolet Provider Service descriptor. The Algolet 
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Provider Service descriptor is described in detail below (illustrated in Fig. 5) ? which 
provides information regarding what analysis capabilities a particular Algolet software 
component is capable of providing. Once an Algolet is identified by processing module 
32 and search engine 33, the Algolet is requested from an Algorithm Lookup Service 
Provider 34. Algorithm Lookup Service Provider 34, which executes a number of 
services that will be described in more detail below and are illustrated in Fig. 6, is 
responsible for acquiring the desired Algolet and its dependent Algolets as requested by 
processing module 32 from the local repository or from other remote Analytical Service 
Providers. An Algolet software component in this embodiment is an Object Oriented 
software component. More specifically, an Algolet is a unit of analysis that may or may 
not be dependent on other Algolets for support analysis and within a parent-sub-class 
relationship. Therefore resolution of a particular Algolet will require acquisition of all 
other Algolets utilized by the requested Algolet software component or parent Algolets 
from which the requested Algolet is derived from. 

Lookup Service Provider 34 thus collects and package all Algolets from its local 
repository 35 and/or from external Analytical Service Provider(s)over a secure 
communications network. The "resolution" of an analysis request consists of a collection 
of Algolet software components passed from Algorithm Service Provider 34 to processing 
module 32. Processing module 32 upon receiving the package of Algolets forwards the 
package to Network Server 3 1 which in turn sends the information back to the requesting 
medical instrument through the same network connection 24. 

The Analytical Service Provider is also capable of acquiring new and updated 
Algolet components as they become available from the Analytical Algorithm 
Development Center (see Fig. 4) through another secure communication network 37. 
New and updated Algolets are sent by the Analytical Algorithm Development Center to 
an Algorithm Update Process 38, which validates and unpacks the updates and installs the 
various components into Algorithm Search Engine 33 and Algorithm Repository 35. 

Analytical Algorithm Development Center 

Fig. 4 shows the final component of the described embodiment, i. e. ? the 
Analytical Algorithm Development Center 13. This is the facility that aggregates and 



12 



cleans up patient and clinician feedback to form the patient database from which existing 
algorithms are improved upon and new algorithms developed to provide new analysis 
capability to address new diseases. It also distributes improved existing and new 
algorithm software components to one or more participating Analytical Service Provider 
service centers. 

As discussed above, an Algolet is a unit of analysis with a well defined domain. 
In the described embodiment, the Algolet encompasses the domain of providing analysis 
of possible Acute Myocardial Infarction (AMI). The analysis of AMI involves 
subcomponents such as AMI in the Anterior region of the heart, AMI in the Inferior 
region of the heart, AMI in the Lateral region of the heart, AMI in the Posterior region of 
the heart, and other confounding and supportive analysis. Thus the creation of such 
analytical components require analysis of patient biological data with the condition from 
which a mathematical model can be constructed. Such a model may be based on Logistic 
Regression that utilize a patient's particular demographic characteristics and confirmed 
diagnosis or the medical condition or disease (e.g. Inferior AMI). For examples of such 
algorithms, the reader is referred to U.S. 4,957,1 15; U.S. 4,998,535; and U.S. 5,277,188, 
all of which are incorporated herein by reference. 

A Patient Data Server 41 receives over secure communications network 210 
patient analysis data from medical instruments described above. Further, the message is 
in the form of a XML-structured message. Patient Data Server 41 is an HTTP internet 
server. The patient analysis data received by Patient Data Server 41 is passed to an 
Aggregation and Clean-Up Process 43 for further processing. Similarly, another HTTP 
internet server 42 receives clinical feedback and confirmation data through 
communication network 21 1 from a clinician (see Fig. 2)or other medical professional or 
information system involved in the care of the patient. The feedback and confirmation 
data is forwarded to Aggregation and Clean-Up Process 43 where it is matched to the 
patient analysis data. Once the patient analysis data and feedback or confirmation data is 
matched and verified, it is then added to a Patient database 44. Both Aggregation and 
Clean-Up Process 43 and Patient database 44 utilize an industry standard relational 
database to process and manage the patient data. 

Periodically, an Improvement Process 45 will review and update its Algolets by 
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executing re-generation of the mathematical data model in which the Algolet is based. 
For example, as the number of patients within the patient population of Male Hispanics 
between the age of 55 and 75 and have confirmed diagnosis of Inferior AMI by various 
clinical means arriving in the Patient Database 44 exceed 10%, Improvement Process 45 
automatically recalculates the mathematical coefficients to a Logistic Regression-based 
algorithm for the Algolet that provides analysis and diagnosis of Inferior AMI for this 
particular patient population. The updated Algolet is then distributed through an 
Algorithm Deployment Process 47 to an Algorithm Distribution Server 48 for 
distribution. Algorithm Distribution Server 48 is a secure HTTP internet server that 
connects to and distributes updates to all subscribing Analytical Service Providers 
through a secure network connection to the Analytical Service Providers. 

As an illustration of a further capability, when the number cases for patients 
within the patient population of Female Pacific Islanders between the age of 35 and 55 
having confirmed diagnosis of Posterior AMI by various clinical means in the Patient 
Database 44 exceeds a preset minimum threshold, a New Algorithm Development 
Process 46 will initiate the creation of an Algolet specifically designed for this patient 
population using Logistic Regression modeling. The newly created Algolet is then 
distributed through Algorithm Deployment Process 47 to Algorithm Distribution Server 
48 for distribution. 

Algolet 

The described embodiment creates and utilizes a software component called an 
Algolet that subscribes to the general practices and methodology of Object Oriented 
Programming design and techniques. Figs. 5.1 and 5.2 depict an embodiment of the 
Algolet software component that encapsulates individual patient analysis algorithm for 
the identification and diagnosis of certain medical conditions and diseases. An Algolet 
5 1 is a software component, referred to as a Class in object oriented terminology, that 
encapsulates a particular medical analysis capability. As in most Object Oriented 
Designs (OOD), an Algolet exposes three interfaces, namely, a Provider Interface 52; a 
Dependencies Interface 53; and a Profile Interface 54. All interfaces provide a set of 
software Application Programming Interface (API) methods for discovering the various 
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capabilities and characteristics of an Algolet. 

Provider Interface 52 provides software API methods to enable a host program to 
find out what services the Algolet is capable of providing. Example methods include 
retrieving a XML-based or DOM-based descriptor of what analysis capabilities the 
Algolet can provide. An example of a XML-based Provider Interface descriptor is given 
below: 

OlgoletProvider ID="iMedical Systems lnc."VERSION-"1 .22.3 A" APPROVAL-'FDA 12345 M > 
<services> 

<service ID="AMI" OUTPUT="Prediction'7> 
<service ID="AMr OUTPUT="Detection7> 
</services> 
</algoletProviderlD> 

The example Provider Interface descriptor indicates the Algolet is capable of 
providing both detection and prediction of AMI. 

Similarly, Dependencies Interface 53 provides software API methods to enable a 
host program to find out what other support Algolet is needed by this Algolet in order to 
fully execute its analysis capabilities as described in Provider Interface 52. An example 
of an XML-based Dependencies Interface descriptor is given below: 

OigoletDependencies ID=" iMedical Systems Inc." VERSION=" 1.22.3 A"> 
<dependencies> 

onaiysis ID-*Anterior AMI7> 
c analysis ID-'Inferior AMI7> 
^dependencies > 
</a!goletDependencies > 

The example Dependencies Interface descriptor indicates the Algolet depends on 
support Algolets that can provide both Anterior AMI and Inferior AMI analysis. The 
dependency descriptor is used by the host program to lookup and collect all Algolets 
necessary to execute the desired analysis. The lookup service is described in more detail 
below. Referring to Fig. 5.2, it can be seen that the dependency descriptor is a link to 
other Algolets through its Provider Interface descriptors as indicated by block 56 and link 
57. The illustration in Fig. 5.2 shows that Algolet A (block 56)is dependent on Algolet 
B and Algolet C, indicated by blocks 58 and 59, respectively. Further, Algolet B is 
dependent on other Algolets indicated by link 510. 

In addition, Profile Interface 54 provides software API methods to enable a host 
program to find out to what patient population context should this Algolet should be 
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applied. The Profile Interface descriptor describes the patient population characteristics 
in which this Algolet is appropriate. This descriptor is used to populate Algorithm 
Search Engine database 33 described above in connection with Fig. 3 for patient Profile 
matching. An example of an XML-based Profile Interface descriptor is provided below: 



olgoletProfile ID="iMedica! Systems Inc." VERS10N=" 1.22.3 A"> 
<demographics> 

<property ID- 'RACE">Caucasian; African American</property> 
<property ID="AGE">45-72</property> 
<property I D=" G E N D E R"> Mai e</property > 
</demographics> 
<medicalHistory> 

<medHx ID="Hypertention ,, >treated</medHx> 
<medHx ID-'Diabetes" >treated</medHx> 
</medicalHistory> 
<vitalSigns> 

<property ID= ,, SBP l, >60-90</property> 
<property ID="DBP">90-130</property> 

<property iD="HEARTRATE" UNITS=" BPM">30-120</property> 
</vitalSigns> 
</algoletProfile > 

The above Profde Interface descriptor indicates the Algolet is appropriate for a 
patient population of Caucasian or African American race, between the ages of 45-72, 
male gender, have had a past history of hypertension and or diabetes, systolic blood 
pressure of 60-90 mmHg, diastolic blood pressure of 90-130 mmHg, and heart rate 
between 30-120 bpm. 

The use of Algolet in its embodiment of Object Oriented Components enables 
precise and manageable methods and processes for creating new diverse and dynamic 
medical analysis software components that plug together to form higher levels of analysis 
capabilities. As interchangeable software components with well defined and exposed 
descriptors become available (such components can be produced by various sources such 
as medical research institutions and commercial entities), they will immediately work 
within the framework of the networked medical instruments and Analytical Service 
Providers, similar to what was described above. 



Analysis Lookup Service 

Fig. 6 presents an Analysis Lookup Service flow chart which shows the 
Analysis Lookup Service and Packaging methodology that exists in the described 
embodiment of the networked medical instrument and Analytical Service Provider. 
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When an analysis request is entered (block 61) such as a request for an Algolet to 
perform detection of AMI, the Service interrogates (block 62) its local repository 63 of 
Algolets for an Algolet that can provide the desired analysis service. The Service tests 
for the condition whether a matching Algolet has been found that can provide the 
requested analysis service (block 64). If no Algolet is found in the local Algolet 
repository (branch 65), the Service opens a network connection to a remote Analytical 
Service Provider over the network such as, but not limited to, an Intranet, the Internet, or 
wireless network (block 66). The desired analysis capability and patient Profile is sent 
over the network (block 67). Analytical Service Providers responding to the request send 
matching Algolet packages back over the same network (block 68) for loading (block 
69). Control is then passed to the Service which tests whether the requested analysis 
capability was found (block 610) (i.e., does the message received contain the desired 
package of Algolets that will satisfy the desired analysis request?). If the appropriate 
Algolet was not found (branch 619), the Service will retrieve a package of default 
Algolets (block 620) and send them to the requestor (block 617) for execution. The 
default Algolets are provided to support conditions where a network is unavailable or the 
requested specialized or targeted analysis capability has not yet been developed. 

In block 64, if a matching Algolet is found in the local repository or in block 610 
if it is found by the remote Analytical Service Provider, the Service passes the package of 
Algolets to a dependency resolution module. The dependency resolution module 
interrogates the Algolets to determine what supporting Algolets they depend on (block 
612). Then, the Service tests whether all dependencies have been collected (block 613). 
If dependencies still exist, the Service passes each dependent Algolet description back for 
a further lookup (block 62). However, if it is determined that all dependencies have been 
resolved, the Service passes the entire package of Algolets out to the requestor of the 
analysis and the process terminates. 

The mathematical model mentioned in connection with the above-described 
embodiment implemented a predictive instrument that predicted cardiac events and/or 
outcomes. More specifically, the predictive instrument is an ACI- TIPI (Acute Cardiac 
Ischemia Time-Insensitive Predictive Instrument) which uses a logistic regression-based 
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equation for computing the probability that the patient is experiencing acute cardiac 
ischemia. The logistic regression equation is of the form: 



where P is the probability of acute cardiac ischemia, bo is a constant, and the bi 's are 
5 coefficients of the variables x* which are included in the model The specific explanatory 

variables and coefficients are described in detail in the patents that have been previously 

mentioned herein (e.g. U.S. 4,957,1 15). 

But the mathematical model or predictive instrument can be designed for 

diagnosing other medical problems beyond the above-described cardiac related problems. 
10 The extension to circumstances that are not cardiac related is straightforward. For 

example, in the domain of pulmonary medicine, a patient in an intensive care unit could 
^ be under observation for potential respiratory failure. The classical approach is to use on- 

going single function monitors of indicators such as the patient's heart rate, respiratory 
m rate, and perhaps under some circumstances, blood oxygen saturation. As with the 
J\ 15 cardiac situation, however, any single one of these parameters has limited utility because 
K of its possible contamination by noise and because of its inherent inability to be a good 

q proxy for the wide variety of clinical features and other factors that are really needed to 
;i provide an accurate estimate of the probability of the medical outcome in question. On 
*I3 the other hand, the mathematical model described herein (e.g., logistic regression) that 

2 20 takes into account the heart rate, blood pressure, respiratory rate, blood oxygen saturation 

level, and perhaps other clinical features, will give a far more accurate indication of and 

prediction of true respiratory failure. The other clinical features include for example the 

patient's age, symptoms (e.g. shortness of breath), and the patient's past medical history 

(e.g., history of smoking, history of prior respiratory failure, etc.). In other words, the 
25 mathematical model will give a more accurate and usable (e.g. noise-free) estimate of the 

patient's condition. 

A further example in the pulmonary area may be useful. In the case of imminent 
respiratory failure, a small increase in respiratory rate and heart rate would likely be 
missed, or might be overwhelmed by noise, or even if detected might be viewed as 
30 insignificant. However, if measured in conjunction with other clinical features, including 
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for example a small decrease in oxygen saturation, these observations when included in a 
logistic regression (or other mathematical model) will be multiplicative, and thus, give a 
substantial (accurate and specific) increase in the computed probability of respiratory 
failure. Thus, since the mathematical model takes multiple factors into account, as in the 
5 cardiac monitor situation, it will provide an opportunity to early on detect a change in the 
computed probability value with sufficient fidelity in the real-time setting to support 
targeted clinical intervention. 

In a generalized monitoring system, the monitor is any device for real-time 
monitoring of one or more clinical features of the patient and the predictive algorithm is 
10 for computing a probability of a medical outcome or diagnosis, based in part on those 
monitored clinical features. The monitoring device could be a single instrument, as it 
was in the case of the above-described cardiac monitor which used an electrocardiograph, 
G or it could be a constellation of medical instruments, as will be the case in some of the 
if] examples systems described below. 

; 1 5 The predictive algorithm uses the output of monitoring device in conjunction with 

^ other clinical information about the patient that has been entered by a physician through 

jy an input device (e.g. keyboard, network connection, database program, etc.) and 
JL computes a probability of a particular medical outcome or diagnosis for the patient. 

In the described embodiments, the probability of the medical diagnosis or medical 
j§ 20 outcome is computed using a logistic regression equation of the following general form: 

]_ 

\ + e z 

where P is the probability of a particular medical outcome or diagnosis, and where z has 
the following general form: 

25 In this equation, b 0 is a constant, and the bi 's are coefficients of the explanatory variables 
xi which are included in the model. The variables that are used in the model will of 
course depend upon the particular medical outcome or diagnosis which is being 
evaluated. Some examples are presented below along with variables that would be 
included in the model. 



P = 100 



1-- 
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Mathematical models other than the logistic regression equation can of course be 
employed. The invention is not limited to the use of a logistic regression equation to 
model the probability of a particular medical outcome or diagnosis. 

The following are further examples of predictive algorithms for non-cardiac 
diagnoses or medical outcomes, along with their likely key clinical variables. 
In the domain of vascular disorders, a predictive algorithm for pulmonary embolus 
includes as key variables the same variables as listed above, as well as a modification of 
the symptoms regarding the suddenness of onset, and also ECG variables related to right 
heart strain (e.g. relating to QRS complex and ST/T wave changes). 

In the domain of neurologic disorders, a predictive algorithm for cerebral 
hemorrhage (i.e., hemorrhagic stroke) includes as key variables the patient's history of 
medications (e.g. anticoagulants, etc.), prior history of cardiac disorders that predispose 
to cerebral thrombosis (e.g. atrial fibrillation, valvular disease), and history of trauma to 
the head, as well as laboratory tests such as prothrombin time and partial thromboplastin 
time and platelet count, which are all measures of the clotting ability of the blood. They 
also include blood pressure, with emphasis on pulse pressure (i.e., a difference between 
the systolic and diastolic pressure). 

In the domain of general surgery, a predictive algorithm for intra-abdominal 
catastrophe (i.e., the need for emergency surgery) includes as key variables the presence 
of abdominal pain, the patient's physical findings by the physician of so-called peritoneal 
signs (rigidity of the abdomen, no bowel sounds, etc.), monitor data such as temperature, 
heart rate, blood pressure, and potentially x-ray findings that reveal bowel gas pattern. 

In the domain of infectious diseases, a predictive algorithm for sepsis (i.e., 
overwhelming infection that would require certain emergency treatments) includes as key 
variables the patient's level of consciousness, specific complaints, and monitored 
physiologic measures such as blood pressure (especially low), heart rate (especially 
high), respiratory rate (especially high), body temperature (especially either unduly high 
or unduly low), ECG abnormalities (as not showing a contrary cardiac cause for 
derangements in heart rate, blood pressure, respiratory rate and other findings in the form 
of an interaction term in the mathematical model) laboratory tests such as white blood 
count (either unduly high or unduly low), interleukin levels, and other special blood tests 
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typically available on-line from hospital clinical information systems. Also, other 
ongoing monitoring data relating to blood and other body fluid culture results, such as are 
typically available on electronic clinical information systems, are further important 
explanatory variables relating to the source of sepsis. 
5 Each of the above diagnoses to be predicted has consequences in terms of clinical 

outcomes including, for example, mortality. Other outcomes that can be predicted by a 
predictive algorithm include mortality due to acute myocardial infarction or congestive 
heart failure, as well as conditional outcomes such as are obtained from the thrombolytic 
predictive algorithm (see U.S. Pat. No. 4,998,535). The use of this approach also applies 
10 to other non-cardiac conditions for which prediction of medical outcomes can be 
conditioned on the use of specific therapies. 

The examples presented above are meant to be merely illustrative of the many 
P ways in which a predictive algorithm can be used to evaluate a patient's medical 
dl condition. It is not intended that the invention be limited to the few examples that were 

: 5 15 described here. In general, the predictive algorithm is any algorithm which computes on 
IP the basis of a set of clinical features a probability of a medical outcome or diagnosis. It is 
m intended that the invention cover the use of such predictive algorithms to evaluate any 
L. medical condition that lends itself to such monitoring, regardless of the particular set of 

03 clinical features and regardless of the particular medical outcome or diagnosis. 

20 By clinical features, it should be understood that we mean any data form that gives direct 
H information about the clinical, i.e., the medical state of patient. Some of the variables 

used in the above descriptions have focused on circumstances in which clinical features 
can be directly acquired in electronic form, such as heart rate and respiratory rate 
acquired by monitors, such as waveforms acquired by an electrocardiograph, such as 
25 oxygen saturation measured by a sensor attached to the patient's finger, and such as 

biochemical laboratory results. However, other clinical features can be obtained in other 
forms and in other ways as well. For example, as described above in connection with the 
use of the cardiac predictive algorithm, direct questioning of the patient provides 
important clinical features, namely, whether or not the patient is having chest pain and 
30 whether chest pains are the chief complaint. Analogously, for a predictive algorithm for 
predicting various respiratory diagnoses or outcomes, a relevant clinical feature would be 
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an indication as to whether the patient has shortness of breath. These symptoms are 
linked to the relevant underlying medical processes and can, in combination with other 
clinical variables in the mathematical model, add important information. And in the case 
of a predictive algorithm for predicting neurologic problems, relevant clinical features 
5 include indications as to whether the patient has a headache and/or neurologic symptoms. 
In addition, some sources of data that are less directly connected to the patient but 
nevertheless still represent important clinical features. For example, sociodemographic 
data such as age and gender are obviously important, as was the case for the cardiac 
predictive algorithm described above. In addition, other relevant clinical feature data is 
10 reflected in medical insurance claims, such as the mere performance of certain tests, the 
fact of hospitalization, the actual diagnostic code (e.g. the ICD9 Code), etc. A clinical 
feature is any piece of additional information about the patient, which when incorporated 
D into a mathematical model predicts a given medical outcome. 
5 A medical outcome or medical diagnosis, such as might be predicted by a 

\Z 15 predictive algorithm, is defined in the following way. A medical outcome is the state of a 
Cm patient defined in medical terms, typically described in the context of a particular 

f|j constellation of presenting symptoms and clinical features. In practice, the outcome is 
L selected to be clinically meaningful to the care of the patient. Therefore, an important 

§3 medical outcome for a patient with a heart attack is mortality. For a person with 

20 respiratory failure, it is also mortality but it is also long-term respiratory disability, which 
O might be defined, for example, as lack of ability to do activities of daily living due to 

3 

shortness of breath as well. For a person with neurologic presenting symptoms, an 
important medical outcome is preservation of normal mental function as well as 
mortality. 

25 There is overlap between the concept of medical outcomes and medical 

diagnoses. For example, when a decision has to be made about a patient, before the 
clinician can evaluate the likely ultimate outcome, the clinician must first consider the 
specific medical diagnosis or family of diagnoses that the patient has which require 
attention. Thus, a diagnosis is, in a sense, an intermediate "outcome". For a person 

30 coming to the emergency department with chest pain and/or other signs and symptoms, 
the first question on the clinician's mind is, what is the diagnosis? If the diagnosis, i.e., 
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the ongoing medical/clinical process, is acute cardiac ischemia (i.e., occlusion of a 
coronary artery), then this requires treatment to prevent its potential downstream 
outcomes from occurring (e.g., death) and that treatment is very different from what 
would be used if the diagnosis is costocondritis (inflammation of the joints of the 
sternum), stomach ulcer, or some other cause of the symptoms. Moreover, for all the 
medical conditions alluded to above, detecting through continuous monitoring of the 
patient changes in the likelihood of such diagnoses can have very important clinical 
implications for treatment. That is, very different treatments are needed for acute cardiac 
ischemia as compared to an ulcer, for respiratory failure as compared to a cold, or for a 
rupture of a cerebral aneurism as compared to a tension headache. Thus, it can be 
critically important to detect when the probability of a medical outcome changes. 

From the above, it should be apparent that the invention described above can be 
used with a wide variety of patient monitoring and predictive devices beyond those used 
for cardiac monitoring. Other monitors with which it can be used include, for example, 
heart rate monitors, respiratory rate monitors, bioanalyzers, blood oximeters, and fetal 
monitors, just to name a few. Of course, in those other cases, the underlying predictive 
instrument instead of predicting the likelihood of the occurrence of a cardiac event would 
predict the occurrence or presence of another medical outcome or diagnosis. 

What is claimed is: 
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